Processing structured and unstructured data using offload processors

ABSTRACT

Methods of processing structured data, unstructured data, or both are disclosed. Processing structured data can include providing an in-memory database with at least one of a plurality of modules connected to a memory bus of a server; executing database functions with at least one processor on the module; and directing database queries to the at least one module with a CPU of the server. Processing unstructured data can include executing data processing tasks with a CPU connected to a memory bus; and directing parallel computation tasks to a plurality of modules connected to the memory bus.

PRIORITY CLAIMS

This application claims the benefit of U.S. Provisional PatentApplication 61/650,373 filed May 22, 2012, the contents of which areincorporated by reference herein.

TECHNICAL FIELD

The present disclosure relates generally to servers capable ofefficiently processing structured and unstructured data. Moreparticularly, systems supporting offload or auxiliary processing modulesthat can be physically connected to a system memory bus to process dataindependent of a host processor of the server are described.

BACKGROUND

Enterprises store and process their large amounts of data in a varietyof ways. One manner in which enterprises store data is by usingrelational databases and corresponding relational database managementsystems (RDBMS). Such data, usually referred to as structured data, maybe collected, normalized, formatted and stored in an RDBMS. Tools basedon standardized data languages such as the Structured Query Language(SQL) may be used for accessing and processing structured data. However,it is estimated that such formatted structured data represents only atiny fraction of an enterprise's stored data. Organizations are becomingincreasingly aware that substantial information and knowledge resides inunstructured data (i.e., “Big Data”) repositories. Accordingly, simpleand effective access to both structured and unstructured data are seenas necessary for maximizing the value of enterprise informationalresources.

However, conventional platforms that are currently being used to handlestructured and unstructured data can substantially differ in theirarchitecture. In-memory processing and Storage Area Network (SAN)-likearchitectures are used for traditional SQL queries, while commodity orshared nothing architectures (each computing node, consisting of aprocessor, local memory, and disk resources, shares nothing with othernodes in the computing cluster) are usually used for processingunstructured data. An architecture that supports both structured andunstructured queries can better handle current and emerging Big Dataapplications.

SUMMARY

Methods can include processing structured and/or unstructured data. Amethod of processing structured data can include providing an in-memorydatabase with at least one of a plurality of modules connected to amemory bus in a first server; executing database functions with at leastone processor on the module; and connecting a central processing unit(CPU) in the first server to the modules by the memory bus, anddirecting database queries to the at least one module.

A method of processing unstructured data can include providing aplurality of modules connected to a memory bus that each include atleast one processor; connecting a central processing unit (CPU) to themodules by the memory bus; executing data processing tasks with the CPU;and directing parallel computation tasks to a plurality of the modules.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows illustrates an embodiment suitable to process structuredqueries.

FIGS. 2-1 and 2-2 are diagrams showing the workflow and distributedarchitecture used to implement a data processing software.

FIG. 3-1 is flow diagram showing a data processing method according toan embodiment.

FIG. 3-2 shows a data processing architecture according to anembodiment.

FIG. 4-1 shows a cartoon schematically illustrating a data processingsystem according to an embodiment, including a removable computationmodule for offload of data processing.

FIG. 4-2 shows an example layout of an in-line module (referred to as a“XIMM”) module according to an embodiment.

FIG. 4-3 shows two possible architectures for a XIMM in a simulation(Xockets MAX and MIN).

FIG. 4-4 shows a representative the power budget for a XIMMs accordingto various embodiments.

FIG. 4-5 illustrates data flow operation of one embodiment using an ARMA9 architecture.

DETAILED DESCRIPTION

Data processing and analytics for enterprise server or cloud based datasystems, including both structured or unstructured data, can beefficiently implemented on offload processing modules connected to amemory bus, for example, by insertion into a socket for a Dual In-lineMemory Module (DIMM). Such modules can be referred to as Xocket™ In-lineMemory Modules (XIMMs), and can have multiple “wimpy” cores associatedwith a memory channel. Using one or more XIMMs it is possible to executelightweight data processing tasks without intervention from a mainserver processor. As will be discussed, XIMM modules have highefficiency context switching, high parallelism, and can efficientlyprocess large data sets. Such systems as a whole are able to handlelarge database searches at a very low power when compared to traditionalhigh power “brawny” server cores. Advantageously, by acceleratingimplementation of MapReduce or similar algorithms on unstructured dataand by providing high performance virtual shared disk for structuredqueries, a XIMM based architecture capable of partitioning tasks is ableto greatly improve data analytic performance.

FIG. 1 illustrates an embodiment to process structured queries accordingto an embodiment. FIG. 1 depicts two commodity computers which can berack servers (140, 140 a), each of which includes at least one centralprocessing unit (108) and a set of offload processors (112 a to 112 c).The servers (140, 140 a) are preferably present in the same rack andconnected by a top of rack (TOR) switch (120). The servers (140, 140 a)are suited for hosting a distributed and shared in-memory assembly (110a, 110 b) that can handle and respond to structured queries as one largein-memory system.

Traditionally, an in-memory database that handles structured querieslooks for the query in its physical memory, and in the absence of thequery therein will perform a disk read to a database. The disk readmight result in the page cache of the kernel being populated with thedisk file. The process might perform a complete copy of the page(s) (ina paged memory system) into its process buffer or it might perform ammap operation, wherein a pointer to the entry in the page cache storingthe pages is created and stored in the heap of the process. The latteris less time consuming and more efficient than the former.

The inclusion of a XIMM supported data retrieval framework caneffectively extend the overall available size of the in-memory spaceavailable with the assembly. In case a structured query is being handledby one of the said CPUs (108), and the CPU is unable to retrieve it fromits main memory, it will immediately trap into a memory map (mmaproutine) that will handle disk reads and populate the page cache.

The embodiment described herein can modify the mmap routine of standardoperating systems to execute code corresponding to a driver for aremovable computation module driver, in this case a XIMM driver. TheXIMM driver in turn identifies the query and transfers the query to oneor more XIMMs in the form of memory reads/writes. A XIMM can house aplurality of offload processors (112 a to 112 c) that can receive thememory read/write commands containing the structured query. One or moreof the offload processors (112 a to 112 c) can perform a search for thequery in its available cache and local memory and return the result.According to embodiments, an mmap query can further be modified to allowthe transference of the query to XIMMs that are not in the same serverbut in the same rack. The mmap abstraction in such a case can perform aremote direct memory access (RDMA) or a similar network memory read foraccessing data present in a XIMM that is in the same rack. As a secondXIMM (i.e., offload processors 112 a to 112 c of server 140 a) isconnected to a first XIMM (i.e., offload processors 112 a to 112 c ofserver 140) through a top of rack switch 120, the latency of a systemaccording to an embodiment can be the combined latency of the networkinterface cards (NICs) of the two servers (i.e., 100 in 140 and 100 in140 a), the latency of the TOR switch 120, and a response time of thesecond XIMM.

Despite the additional hops, embodiments can provide a system that canhave a much lower latency than a read from a hard disk drive. Thedescribed architecture can provide orders of magnitude improvement overa single structured query in-memory database. By allowing fornon-frequently used data of one of the servers to be pushed to anotherXIMM located in the same rack, the effective in-memory space can beincreased beyond conventional limits, and a large assembly having alarge physical, low latency memory space can be created. This embodimentmay further be improved by allowing for transparent sharing of pagesacross multiple XIMMs. Embodiments can further improve the latencybetween server-to-server connections by mediating them by XIMMs. TheXIMMs can act as intelligent switches to offload and bypass the TORswitch.

Conventional data intensive computing platforms for handling largevolumes of unstructured data can use a parallel computing approachcombining multiple processors and disks in large commodity computingclusters connected with high-speed communications switches and networks.This can allow the data to be partitioned among the available computingresources and processed independently to achieve performance andscalability based on the amount of data. A variety of distributedarchitectures have been developed for data-intensive computing andseveral software frameworks have been proposed to process unstructureddata. One such programming model for processing large data sets with aparallel, distributed algorithm on a multiple servers or clusters iscommonly known as MapReduce. Hadoop is a popular open-sourceimplementation of MapReduce that is widely used by enterprises forsearch of unstructured data.

FIGS. 2-1 and 2-2 show the workflow and distributed architecture used toimplement a data processing software, such as Hadoop. Referring to FIG.2-1, Hadoop MapReduce workloads may be broken into Split, Map, Shuffle,Reduce and Merge phases. The input file (204) is fetched from a filesystem such as Hadoop Distributed File System (HDFS) (202) and dividedinto smaller pieces referred to as Splits. Each Split (206) is acontiguous range of the input. Each record in each input split isindependently passed to a Map function run by a Mapper (208) hosted on aprocessor. The Map function accepts a single record as an input andproduces zero or more output records, each of which contains a key and avalue. In the Shuffle phase (210), the results from the Map functions,referred to as intermediate (key, value) pairs, are rearranged such thatall values with the same key are grouped together. The Reduce functionrun by a Reducer (212) takes in a key value and a list values as theinput and produces another list as the output. The output records fromReduce functions are merged to form an Output file (216) which is thenstored in the file system (202).

Map and Reduce tasks are computationally intensive and have very tightdependency on each other. While Map tasks are small and independenttasks that can run in parallel, the Reduce tasks include fetchingintermediate (key, value) pairs that result from each Map function,sorting and merging intermediate results according to keys and applyingReduce functions to the sorted intermediate results. Reducer (212) canperform the Reduce function only after it receives the intermediateresults from all the Mappers (208). Thus, the Shuffle step (210)(communicating the Map results to Reducers) often becomes the bottleneckin Hadoop workloads and introduces latency.

FIG. 2-2 shows a typical computing cluster used to implement Hadoop. AMaster Node (222) runs a JobTracker (224) which organizes the cluster'sactivities. Each of the Worker Nodes (326) run a TaskTracker (228) whichorganizes the worker node's activities. All input jobs are organizedinto sequential tiers of tasks (230). The tasks could be map tasks orreduce tasks. The TaskTracker (228) runs a number of map and reducetasks concurrently and pulls new tasks from the JobTracker (224) as soonas the old tasks are completed. The Hadoop Map-Reduce layer storesintermediate data (232) produced by the map and reduce tasks in theHadoop Distributed File System (202) discussed in FIG. 2-1. HDFS (202)is designed to provide high streaming throughput to large,write-once-read-many-times files.

In an embodiment, a XIMM based architecture can improve Hadoop (orsimilar data processing) performance in two ways. Firstly, intrinsicallyparallel computational tasks can be allocated to the XIMMs (e.g.,modules with offload processors), leaving the number crunching tasks to“brawny” (e.g., x86) cores. This is illustrated in more detail in FIG.3-1.

FIG. 3-1 is flow diagram showing a data processing method according toan embodiment. A method can start (302) and input data can be fetchedfrom a file system (304). In particular embodiments this can include aDirect Memory Access (DMA) operation from an HDFS. In some embodiments,all DMA operations are engineered such that all the parallel Map stepsare equitably served with data. The input data can be partitioned intosplits in (306) and parsed into records that contain initial (key,value) pairs in (308). Since the tasks involved in steps (304, 306 and308) are computationally light, they can be performed all, or in part,by the offload processors hosted on the XIMMs (e.g., by wimpy cores).Map operations can then be performed on the initial (key, value) pairs(310). The intermediate (key, value) pairs that result from the Mapoperations can then be communicated to the Reducers (312). Once theresults from all the Map operations are available, Reduce operations canbe performed (314). The results from the Reducers are merged into asingle output file and written back to the file system (e.g., 302) byoffload processors (316). Since Map and Reduce functions arecomputationally intensive, the steps (310 and 314) can be handled by aCPU (e.g., by brawny cores). Such distribution of workloads to processorcores that are favorably disposed to perform them can reduce latencyand/or increases efficiency.

A XIMM based architecture, according to an embodiment, can reduce theintrinsic bottleneck of most Hadoop (or similar data processing)workloads (the Shuffle phase) by driving the I/O backplane to its fullcapacity. In a conventional Hadoop system, the TaskTracker (228)described in FIG. 2-2 serves hyper-text transport protocol (HTTP) GETrequests to communicate Map results to Reduce inputs. Also, the Mappersand Reducers hosted by the individual server CPUs have to communicateusing their corresponding top of rack (TOR) switches of thecorresponding racks. This slows down the process. Further, the Reducershosted by the CPU stay idle while the results from Map operations arecollected and sorted, introducing further computational inefficiency.

FIG. 3-2 shows a data processing architecture according to anembodiment. In the architecture illustrated in FIG. 3-2, operationalmodules are labeled to reflect their primary operations as previouslynoted with respect to FIG. 3-1. In an embodiment, instead of using HTTPto communicate, a publish-subscribe model is used to perform theShuffling phase as shown in FIG. 3-2. Since the results from the Mapstep (310) are already stored and available in main memory, they can becollected through DMA operations (312 a) and parsed (312 b) by XIMMs.Since Map results are not required to be written to disk, latency can bereduced. Further, the XIMMs incorporated into the individual servers candefine a switch fabric that can be used for Shuffling. The mid-planedefined by the XIMM based switch fabric is capable of driving andreceiving the full 240 Gbps capacity of the PCI-3.0 bus and thus offersbetter speed and bandwidth compared to HTTP. The key is publishedthrough the massively parallel I/O mid-plane defined by the XIMMs (312a). Subscriptions are identified based on the keys and are directed tothe Reducers hosted on the CPU through virtual interrupts (312 b). Thus,rack-level locality and aggregation that are typical of conventionalHadoop systems are no longer required in the XIMM based architecture.Instead, intermediate (key, value) pairs are exchanged by all thecomputing nodes across several different servers through intelligentvirtual switching of the XIMMs resulting in efficient processing ofHadoop workloads.

The following example(s) provide illustration and discussion ofexemplary hardware and data processing systems suitable forimplementation and operation of the foregoing discussed systems andmethods. In particular hardware and operation of wimpy cores orcomputational elements connected to a memory bus and mounted in DIMM orother conventional memory socket is discussed.

FIG. 4-1 is a cartoon schematically illustrating a data processingsystem 400 including a removable computation module 402 for offload ofdata processing from x86 or similar main/server processors 403 tomodules connected to a memory bus 403. Such modules 402 can be XIMMmodules, as described herein or equivalents, and can have multiplecomputation elements that can be referred to as “offload processors”because they offload various “light touch” processing tasks such HTML,video, packet level services, security, or data analytics. This is ofparticular advantage for applications that require frequent randomaccess or application context switching, since many server processorsincur significant power usage or have data throughput limitations thatcan be greatly reduced by transfer of the computation to lower power andmore memory efficient offload processors.

The computation elements or offload processors can be accessible throughmemory bus 405. In this embodiment, the module can be inserted into aDual Inline Memory Module (DIMM) slot on a commodity computer or serverusing a DIMM connector (407), providing a significant increase ineffective computing power to system 400. The module (e.g., XIMM) maycommunicate with other components in the commodity computer or servervia one of a variety of busses including but not limited to any versionof existing double data rate standards (e.g., DDR, DDR2, DDR3, etc.)

This illustrated embodiment of the module 402 contains five offloadprocessors (400 a, 400 b, 400 c, 400 d, 400 e) however other embodimentscontaining greater or fewer numbers of processors are contemplated. Theoffload processors (400 a to 400 e) can be custom manufactured or one ofa variety of commodity processors including but not limited tofield-programmable grid arrays (FPGA), microprocessors, reducedinstruction set computers (RISC), microcontrollers or ARM processors.The computation elements or offload processors can include combinationsof computational FPGAs such as those based on Altera, Xilinx (e.g.,Artix™ class or Zynq® architecture, e.g., Zynq® 7020), and/orconventional processors such as those based on Intel Atom or ARMarchitecture (e.g., ARM A9). For many applications, ARM processorshaving advanced memory handling features such as a snoop control unit(SCU) are preferred, since this can allow coherent read and write ofmemory. Other preferred advanced memory features can include processorsthat support an accelerator coherency port (ACP) that can allow forcoherent supplementation of the cache through an FPGA fabric orcomputational element.

Each offload processor (400 a to 400 e) on the module 402 may run one ofa variety of operating systems including but not limited to Apache orLinux. In addition, the offload processors (400 a to 400 e) may haveaccess to a plurality of dedicated or shared storage methods. In thisembodiment, each offload processor can connect to one or more storageunits (in this embodiments, pairs of storage units 404 a, 404 b, 404 cand 404 d). Storage units (404 a to 404 d) can be of a variety ofstorage types, including but not limited to random access memory (RAM),dynamic random access memory (DRAM), sequential access memory (SAM),static random access memory (SRAM), synchronous dynamic random accessmemory (SDRAM), reduced latency dynamic random access memory (RLDRAM),flash memory, or other emerging memory standards such as those based onDDR4 or hybrid memory cubes (HMC).

FIG. 4-2 shows an example layout of a module (e.g., XIMM) such as thatdescribed in FIG. 4-1, as well as a connectivity diagram between thecomponents of the module. In this example, five Xilinx™ Zynq® 7020 (416a, 416 b, 416 c, 416 d, 416 e and 416 in the connectivity diagram)programmable systems-on-a-chip (SoC) are used as computationalFPGAs/offload processors. These offload processors can communicate witheach other using memory-mapped input-output (MMIO) (412). The types ofstorage units used in this example are SDRAM (SD, one shown as 408) andRLDRAM (RLD, three shown as 406 a, 406 b, 406 c) and an Inphi™ iMB02memory buffer 418. Down conversion of 3.3 V to 2.5 volt is required toconnect the RLDRAM (406 a to 406 c) with the Zynq® components. Thecomponents are connected to the offload processors and to each other viaa DDR3 (414) memory bus. Advantageously, the indicated layout maximizesmemory resources availability without requiring a violation of thenumber of pins available under the DIMM standard.

In this embodiment, one of the Zynq® computational FPGAs (416 a to 416e) can act as arbiter providing a memory cache, giving an ability tohave peer to peer sharing of data (via memcached or OMQ memoryformalisms) between the other Zynq® computational FPGAs (416 a to 416e). Traffic departing for the computational FPGAs can be controlledthrough memory mapped I/O. The arbiter queues session data for use, andwhen a computational FPGA asks for address outside of the providedsession, the arbiter can be the first level of retrieval, externalprocessing determination, and predictors set.

FIG. 4-3 shows two possible architectures for a module (e.g., XIMM) in asimulation (Xockets MAX and MIN). Xockets MIN (420 a) can be used inlow-end public cloud servers, containing twenty ARM cores (420 b) spreadacross fourteen DIMM slots in a commodity server which has two Opteronx86 processors and two network interface cards (NICs) (420 c). Thisarchitecture can provide a minimal benefit per Watt of power used.Xockets MAX (422 a) contains eighty ARM cores (422 b) across eight DIMMslots, in a server with two Opteron x86 processors and four NICs (422c). This architecture can provide a maximum benefit per Watt of powerused.

FIG. 4-4 shows a representative power budget for an example of a module(e.g., XIMM) according to a particular embodiment. Each component islisted (424 a, 424 b, 424 c, 424 d) along with its power profile.Average total and total wattages are also listed (426 a, 426 b). Intotal, especially for I/O packet processing with packet sizes on theorder 1 KB in size, module can have a low average power budget that iseasily able to be provided by the 22 V_(dd) pins per DIMM. Additionally,the expected thermal output can be handled by inexpensive conductiveheat spreaders, without requiring additional convective, conductive, orthermoelectric cooling. In certain situations, digital thermometers canbe implemented to dynamically reduce performance (and consequent heatgeneration) if needed.

Operation of one embodiment of a module 430 (e.g., XIMM) using an ARM A9architecture is illustrated with respect to FIG. 4-5. Use of ARM A9architecture in conjunction with an FPGA fabric and memory, in this caseshown as reduced latency DRAM (RLDRAM) 438, can simplify or makespossible zero-overhead context switching, memory compression and CPI, inpart by allowing hardware context switching synchronized with networkqueuing. In this way, there can be a one-to-one mapping between threadand queues. As illustrated, the ARM A9 architecture includes a SnoopControl Unit 432 (SCU). This unit allows one to read out and write inmemory coherently. Additionally, the Accelerator Coherency Port 434(ACP) allows for coherent supplementation of the cache throughout theFPGA 436. The RLDRAM 438 provides the auxiliary bandwidth to read andwrite the ping-pong cache supplement (435): Block1$ and Block2$ duringpacket-level meta-data processing.

The following table (Table 1) illustrates potential states that canexist in the scheduling of queues/threads to XIMM processors and memorysuch as illustrated in FIG. 4-5.

TABLE 1 Queue/Thread State HW treatment Waiting for Ingress All ingressdata has been processed and thread Packet awaits further communication.Waiting for MMIO A functional call to MM hardware (such as HW encryptionor transcoding) was made. Waiting for Rate-limit The thread's resourceconsumption exceeds limit, due to other connections idling. Currentlybeing One of the ARM cores is already processing processed this thread,cannot schedule again. Ready for Selection The thread is ready forcontext selection.These states can help coordinate the complex synchronization betweenprocesses, network traffic, and memory-mapped hardware. When a queue isselected by a traffic manager a pipeline coordinates swapping in thedesired L2 cache (440), transferring the reassembled 10 data into thememory space of the executing process. In certain cases, no packets arepending in the queue, but computation is still pending to serviceprevious packets. Once this process makes a memory reference outside ofthe data swapped, a scheduler can require queued data from a networkinterface card (NIC) to continue scheduling the thread. To provide fairqueuing to a process not having data, the maximum context size isassumed as data processed. In this way, a queue must be provisioned asthe greater of computational resource and network bandwidth resource,for example, each as a ratio of an 800 MHz A9 and 3 Gbps of bandwidth.Given the lopsidedness of this ratio, the ARM core is generallyindicated to be worthwhile for computation having many parallel sessions(such that the hardware's prefetching of session-specific data andTCP/reassembly offloads a large portion of the CPU load) and thoserequiring minimal general purpose processing of data.

Essentially zero-overhead context switching is also possible usingmodules as disclosed in FIG. 4-5. Because per packet processing hasminimum state associated with it, and represents inherent engineeredparallelism, minimal memory access is needed, aside from packetbuffering. On the other hand, after packet reconstruction, the entirememory state of the session can be accessed, and so can require maximalmemory utility. By using the time of packet-level processing to prefetchthe next hardware scheduled application-level service context in twodifferent processing passes, the memory can always be available forprefetching. Additionally, the FPGA 436 can hold a supplemental“ping-pong” cache (435) that is read and written with every contextswitch, while the other is in use. As previously noted, this is enabledin part by the SCU 432, which allows one to read out and write in memorycoherently, and ACP 434 for coherent supplementation of the cachethroughout the FPGA 436. The RLDRAM 438 provides for read and write tothe ping-pong cache supplement (435): (shown as Block1$ and Block2$)during packet-level meta-data processing. In the embodiment shown, onlylocally terminating queues can prompt context switching.

In operation, metadata transport code can relieve a main or hostprocessor from tasks including fragmentation and reassembly, andchecksum and other metadata services (e.g., accounting, IPSec, SSL,Overlay, etc.). As 10 data streams in and out, L1 cache 437 can befilled during packet processing. During a context switch, the lock-downportion of a translation lookaside buffer (TLB) of an L1 cache can berewritten with the addresses corresponding to the new context. In onevery particular implementation, the following four commands can beexecuted for the current memory space.

MRC p15, 0, r0, c10, c0, 0; read the lockdown register

BIC r0, r0, #1; clear preserve bit

MCR p15, 0, r0, c10, c0, 0; write to the lockdown register;

write to the old value to the memory mapped Block RAM

This is a small 32 cycle overhead to bear. Other TLB entries can be usedby the XIMM stochastically.

Bandwidths and capacities of the memories can be precisely allocated tosupport context switching as well as applications such as Openflowprocessing, billing, accounting, and header filtering programs.

For additional performance improvements, the ACP 434 can be used notjust for cache supplementation, but hardware functionalitysupplementation, in part by exploitation of the memory space allocation.An operand can be written to memory and the new function called, throughcustomizing specific Open Source libraries, so putting the thread tosleep and a hardware scheduler can validate it for scheduling again oncethe results are ready. For example, OpenVPN uses the OpenSSL library,where the encrypt/decrypt functions 439 can be memory mapped. Largeblocks are then available to be exported without delay, or consuming theL2 cache 440, using the ACP 434. Hence, a minimum number of calls areneeded within the processing window of a context switch, improvingoverall performance.

It should be appreciated that in the foregoing description of exemplaryembodiments of the invention, various features of the invention aresometimes grouped together in a single embodiment, figure, ordescription thereof for the purpose of streamlining the disclosureaiding in the understanding of one or more of the various inventiveaspects. This method of disclosure, however, is not to be interpreted asreflecting an intention that the claimed invention requires morefeatures than are expressly recited in each claim. Rather, as thefollowing claims reflect, inventive aspects lie in less than allfeatures of a single foregoing disclosed embodiment. Thus, the claimsfollowing the detailed description are hereby expressly incorporatedinto this detailed description, with each claim standing on its own as aseparate embodiment of this invention.

It is also understood that the embodiments of the invention may bepracticed in the absence of an element and/or step not specificallydisclosed. That is, an inventive feature of the invention may beelimination of an element.

Accordingly, while the various aspects of the particular embodiments setforth herein have been described in detail, the present invention couldbe subject to various changes, substitutions, and alterations withoutdeparting from the spirit and scope of the invention.

What is claimed is:
 1. A method of processing structured data,comprising: providing an in-memory database with at least one of aplurality of modules connected to a memory bus in a first server;executing database functions with at least one processor on the module;and connecting a central processing unit (CPU) in the first server tothe modules by the memory bus, and directing database queries to the atleast one module.
 2. The method of processing structured data of claim1, further including communicating between modules without accessing anyCPU of the first server.
 3. The method of processing structured data ofclaim 1, further including: the modules are mounted on different serversin a same rack; and communicating between modules of different rackswith a top of the rack switch.
 4. The method of processing structureddata of claim 1, further including executing a memory mapping operationto transfer a database query from the CPU to at least one module in theform of a memory read or write.
 5. The method of processing structureddata claim 1, wherein providing the in-memory database includesinserting the modules into dual-in-line-memory-module (DIMM) sockets. 6.A method of processing unstructured data, comprising the steps of:providing a plurality of modules connected to a memory bus that eachinclude at least one processor; connecting a central processing unit(CPU) to the modules by the memory bus; executing data processing taskswith the CPU; and directing parallel computation tasks to a plurality ofthe modules.
 7. The method of processing unstructured data of claim 6,further including: executing a Map/Reduce algorithm, includingcollecting data parsed with a plurality of the modules, and storingresults of a Map step in a main memory
 8. The method of processingunstructured data of claim 6, further including defining a massivelyparallel input/output (I/O) mid-plane with a plurality of the modules.9. The method of processing unstructured data of claim 6, furtherincluding: the modules are mounted on different servers in a same rack;processing a Map/Reduce algorithm with multiples of the servers; andexchanging intermediate (key, value) pairs across the multiple serversthrough switching by the modules.
 10. The method of processingunstructured data of claim 6, wherein providing the plurality of modulesconnected to a memory bus includes inserting the modules intodual-in-line-memory-module (DIMM) sockets.